Field of the Invention
The invention relates generally to database management. More particularly, embodiments relate to methods to manage database licensing.
Background Art
In many industry applications, a large amount of data is generated, collected, and deposited to a database. For example, in the oil and gas industry especially during oil Exploration and Production (E&P), geological formation data are collected in the exploration stage. These geological formation data are stored for the use of making decisions on where to drill. In the production stage, data on oil and gas flow rates are collected to monitor the production processes. A large investment is often needed to build a database. It is essential that all the data are stored and managed in such an efficient way that subsequent search and use of the data are facilitated. Besides efficiently organizing data, a Database Management Systems (DBMS) often needs a licensing service in order to grant licensed users access to databases efficiently, while denying unlicensed user accesses, as the data contain confidential and/or priority information and possibly other valuable intellectual property.
The market of local DBMS is dominated by client-server products called SQL Servers, developed by Sybase and Microsoft. SQL Servers are based on the Structural Query Language (SQL). SQL Servers are popular in low-end applications in small businesses and local offices where the local DBMS run on stand-alone desktops and laptops. This is because SQL Servers are of low cost, simple administration, and good performance, as a result of being based on the popular Windows™ NT technology. On the other hand, Oracle™ dominates the high-end database market (such as corporate and national repositories) because of its high scalability, reliability, and a wide assortment of features. Oracle and SQL Servers have many differences, and it is often difficult to support applications on both Oracle and SQL Server. Software vendors (and hence users) are often forced to choose one platform over the other. Migrating data from one platform to another and merging data may require extensive effort. Further, a customized DBMS is often required to run on different platforms.
In the following context, a database instance and a DBMS are collectively referred to as a “data repository”. A database instance can have many data stores. A data store contains a collection of tables and views. A table is an array of data. A view is a particular way of looking at a table, and the change of a view does not affect the physical organization of a table. Users are typically not granted access to the tables directly. They are granted access to views of the tables. A view in a data store provides a standard interface to that data store. Tables and views can be private or public. Conventionally, for a database entity XYZ, a private implementation of a table is represented with XYZ_, and a public interface view is represented with XYZ. The data in a data repository are usually related among themselves, and such a relation is usually defined by a logical specification in the form of a “data model.”
In Oracle and SQL Server, as well as in other commercial DBMS, as long as a user has a valid license and the license is checked out, the user is granted access to the whole database. For example, the Oracle database controls user access through log-on and log-off triggers, which are SQL procedures (i.e., code segments) that initiate an action of granting or denying access to the whole database when a user attempts to log on. However, a database may include many subsets of entity types in the data model, referred to as “domains.” For example, in an oilfield service setting, the domains include Drilling, Production, Log, Reservoir, Seismic, and Well. These domains could have very different sizes. For example, the Well domain could be relatively inexpensive because it is relatively small and simple. The Production domain could be large and complex and hence very expensive to develop.
Traditional schemes for database licensing allow a licensed user to access the whole database, as shown in prior art FIG. 1. The database (100) includes one or more domains (Domain A (101), Domain B (102), Domain C (103), Domain D (104), Domain E (105)), and is protected by a security shell (110). User N (106) with a valid license (License XYZ (107)) is allowed to cross the security shell (110) and thus have unrestricted access to all the domains (Domain A (101), Domain B (102), Domain C (103), Domain D (104), Domain E (105)) associated with the database (100). User B (108) without a valid license (or a license to an unsupported database) is not allowed to cross the security shell (100) and therefore has no access to the domains associated with the database (100). Accordingly, a user is either given complete access or none at all.
Allowing licensing by specific domains (e.g., a subset of one or more of Domain A (101), Domain B (102), Domain C (103), Domain D (104), Domain E (105)) in a conventional manner requires a DBMS to check for each procedure, referred to as a “probe”, that attempts to access each of the one or more domains to determine whether a domain-specific license is checked out for that user. Because of the complexity and scale of a database, many probes are executed when a user attempts to access the database, and subsequently many license checks are required.
When managing a large data repository, it is often necessary to allow third party applications to access the database. Many third party applications may need to execute in conjunction with the database (and therefore necessarily need a license to access the database). In conventional practice, the licensing fees for such limited third party application usage are the same as that for a user with direct access to the database. However, these third party applications do not provide open access for users to the complete database, so charging a full licensing fee is not warranted.